راهنمای جامع خط‌مشی امنیت محتوا (CSP) و دیگر هدرهای امنیتی فرانت‌اند برای محافظت از اپلیکیشن‌های وب در برابر حملات و افزایش امنیت کاربران در سراسر جهان.
هدرهای امنیتی فرانت‌اند: تسلط بر خط‌مشی امنیت محتوا (CSP)
در چشم‌انداز دیجیتال امروز، جایی که اپلیکیشن‌های وب به طور فزاینده‌ای پیچیده و به هم پیوسته هستند، حفاظت در برابر تهدیدات امنیتی امری حیاتی است. در حالی که امنیت بک‌اند (backend) اغلب توجه قابل توجهی را به خود جلب می‌کند، امنیت فرانت‌اند (frontend) نیز به همان اندازه حیاتی است. هدرهای امنیتی فرانت‌اند به عنوان اولین خط دفاعی عمل می‌کنند و مکانیزمی را برای دستور دادن به مرورگر در مورد نحوه رفتار و محافظت از کاربران در برابر حملات مختلف فراهم می‌کنند. در میان این هدرها، خط‌مشی امنیت محتوا (Content Security Policy یا CSP) به عنوان یک ابزار قدرتمند برای کاهش طیف گسترده‌ای از خطرات برجسته است.
هدرهای امنیتی فرانت‌اند چه هستند؟
هدرهای امنیتی فرانت‌اند، هدرهای پاسخ HTTP هستند که یک وب سرور به مرورگر ارسال می‌کند. این هدرها حاوی دستورالعمل‌هایی در مورد چگونگی مدیریت محتوای دریافتی توسط مرورگر هستند. آنها به جلوگیری از حملات رایج مانند موارد زیر کمک می‌کنند:
- اسکریپت‌نویسی بین سایتی (XSS): تزریق اسکریپت‌های مخرب به وب‌سایت‌های مورد اعتماد.
- کلیک‌جکینگ (Clickjacking): فریب دادن کاربران برای کلیک کردن روی چیزی متفاوت از آنچه تصور می‌کنند.
- حملات مرد میانی (Man-in-the-Middle Attacks): رهگیری ارتباط بین کاربر و سرور.
برخی از مهم‌ترین هدرهای امنیتی فرانت‌اند عبارتند از:
- خط‌مشی امنیت محتوا (CSP): منابعی را که مرورگر مجاز به بارگذاری آنها است، تعریف می‌کند.
- Strict-Transport-Security (HSTS): مرورگر را مجبور می‌کند تا از HTTPS برای تمام ارتباطات با وب‌سایت استفاده کند.
- X-Frame-Options: از جاسازی وب‌سایت در یک iframe جلوگیری می‌کند و حملات کلیک‌جکینگ را کاهش می‌دهد.
- X-XSS-Protection: فیلتر XSS داخلی مرورگر را فعال می‌کند. (توجه: اغلب با CSP جایگزین می‌شود اما همچنان می‌تواند یک لایه دفاعی ایجاد کند).
- Referrer-Policy: میزان اطلاعات ارجاع‌دهنده (referrer) ارسالی با درخواست‌ها را کنترل می‌کند.
- Feature-Policy (اکنون Permissions-Policy): به توسعه‌دهندگان اجازه می‌دهد تا ویژگی‌ها و APIهای مرورگر را به صورت انتخابی فعال و غیرفعال کنند.
بررسی عمیق خط‌مشی امنیت محتوا (CSP)
خط‌مشی امنیت محتوا (CSP) یک هدر پاسخ HTTP است که منابعی را که عامل کاربر (user agent) مجاز به بارگذاری برای یک صفحه خاص است، کنترل می‌کند. این هدر اساساً منابع محتوای تایید شده را در لیست سفید (whitelist) قرار می‌دهد و به طور قابل توجهی خطر حملات XSS را کاهش می‌دهد. با تعریف صریح مبداهایی که منابعی مانند اسکریپت‌ها، شیوه‌نامه‌ها، تصاویر و فونت‌ها می‌توانند از آنها بارگذاری شوند، CSP تزریق کد مخرب به وب‌سایت شما را برای مهاجمان بسیار دشوارتر می‌کند.
CSP چگونه کار می‌کند
CSP با ارائه لیستی از منابع تایید شده برای انواع مختلف محتوا به مرورگر کار می‌کند. هنگامی که مرورگر با منبعی مواجه می‌شود که CSP را نقض می‌کند، آن منبع را مسدود کرده و تخلف را گزارش می‌دهد. این مکانیسم مسدودسازی از اجرای کد مخرب جلوگیری می‌کند، حتی اگر یک مهاجم موفق به تزریق آن به HTML شود.
دستورالعمل‌های CSP
دستورالعمل‌های CSP اجزای اصلی یک خط‌مشی CSP هستند. آنها منابع مجاز برای انواع مختلف منابع را مشخص می‌کنند. برخی از دستورالعمل‌های رایج عبارتند از:
- default-src: منبع پیش‌فرض را برای همه انواع منابع تنظیم می‌کند. این یک دستورالعمل جایگزین است که زمانی اعمال می‌شود که دستورالعمل‌های مشخص‌تر دیگر تعریف نشده باشند.
- script-src: منابع مجاز برای جاوا اسکریپت را مشخص می‌کند.
- style-src: منابع مجاز برای شیوه‌نامه‌های CSS را مشخص می‌کند.
- img-src: منابع مجاز برای تصاویر را مشخص می‌کند.
- font-src: منابع مجاز برای فونت‌ها را مشخص می‌کند.
- media-src: منابع مجاز برای صدا و ویدئو را مشخص می‌کند.
- object-src: منابع مجاز برای پلاگین‌هایی مانند Flash را مشخص می‌کند. (به طور کلی بهتر است در صورت امکان از اجازه دادن به پلاگین‌ها خودداری شود).
- frame-src: منابع مجاز برای فریم‌ها (iframes) را مشخص می‌کند.
- connect-src: منابع مجاز برای درخواست‌های شبکه (AJAX، WebSockets) را مشخص می‌کند.
- base-uri: URLهایی را که می‌توانند در یک عنصر
<base>استفاده شوند، محدود می‌کند. - form-action: URLهایی را که فرم‌ها می‌توانند به آنها ارسال شوند، محدود می‌کند.
- frame-ancestors: والدین معتبری را که ممکن است یک صفحه را با استفاده از
<frame>،<iframe>،<object>،<embed>یا<applet>جاسازی کنند، مشخص می‌کند. این دستورالعمل در برابر کلیک‌جکینگ محافظت می‌کند. - upgrade-insecure-requests: به عامل‌های کاربر دستور می‌دهد تا با تمام URLهای ناامن یک سایت (که از طریق HTTP بارگذاری شده‌اند) طوری رفتار کنند که گویی با URLهای امن (که از طریق HTTPS بارگذاری شده‌اند) جایگزین شده‌اند. این دستورالعمل برای وب‌سایت‌هایی است که در حال مهاجرت از HTTP به HTTPS هستند.
- report-uri: یک URL را مشخص می‌کند که مرورگر باید گزارش‌های مربوط به نقض CSP را به آن ارسال کند. به نفع `report-to` منسوخ شده است.
- report-to: یک نام گروه تعریف شده در هدر `Report-To` را مشخص می‌کند. این امکان کنترل دقیق‌تری بر گزارش‌دهی، از جمله مشخص کردن چندین نقطه پایانی گزارش‌دهی را فراهم می‌کند.
مقادیر منبع در CSP
مقادیر منبع، مبداهایی را که منابع مجاز به بارگذاری از آنها هستند، تعریف می‌کنند. برخی از مقادیر منبع رایج عبارتند از:
- *: اجازه محتوا از هر منبعی را می‌دهد (از این مورد در محیط production استفاده نکنید!).
- 'self': اجازه محتوا از همان مبدا (طرح، میزبان و پورت) سند محافظت شده را می‌دهد.
- 'none': اجازه محتوا از هیچ منبعی را نمی‌دهد.
- 'unsafe-inline': اجازه استفاده از جاوا اسکریپت و CSS درون‌خطی (inline) را می‌دهد (از این مورد در محیط production استفاده نکنید!).
- 'unsafe-eval': اجازه استفاده از ارزیابی کد پویا (مانند
eval()،Function()) را می‌دهد (از این مورد در محیط production استفاده نکنید!). - 'strict-dynamic': مشخص می‌کند که اعتمادی که به صراحت به یک اسکریپت موجود در نشانه‌گذاری، با همراهی آن با یک nonce یا هش، داده شده است، باید به تمام اسکریپت‌های بارگذاری شده توسط آن والد منتقل شود.
- 'unsafe-hashes': اجازه به کنترل‌کننده‌های رویداد درون‌خطی خاصی می‌دهد. این مورد به دلیل پیچیدگی و مزیت محدودش عموماً توصیه نمی‌شود.
- data:: اجازه بارگذاری منابع از URLهای داده (مثلاً تصاویر جاسازی شده) را می‌دهد. با احتیاط استفاده کنید.
- mediastream:: اجازه می‌دهد تا URIهای `mediastream:` به عنوان منبع رسانه استفاده شوند.
- blob:: اجازه می‌دهد تا URIهای `blob:` به عنوان منبع رسانه استفاده شوند.
- filesystem:: اجازه می‌دهد منابع از یک سیستم فایل بارگذاری شوند.
- https://example.com: اجازه محتوا از یک دامنه و پورت خاص را می‌دهد.
- *.example.com: اجازه محتوا از هر زیردامنه‌ای از example.com را می‌دهد.
- nonce-{random-value}: اجازه به اسکریپت‌ها یا استایل‌هایی با ویژگی nonce منطبق می‌دهد. این امر نیازمند تولید یک مقدار nonce تصادفی در سمت سرور برای هر درخواست است.
- sha256-{hash-value}: اجازه به اسکریپت‌ها یا استایل‌هایی با هش SHA256، SHA384 یا SHA512 منطبق می‌دهد.
حالت‌های CSP: اجرایی در برابر فقط-گزارش (Report-Only)
CSP را می‌توان در دو حالت مستقر کرد:
- حالت اجرایی (Enforce Mode): در این حالت، مرورگر هر منبعی را که CSP را نقض کند، مسدود می‌کند. این حالت توصیه شده برای محیط‌های production است. CSP با استفاده از هدر `Content-Security-Policy` ارسال می‌شود.
- حالت فقط-گزارش (Report-Only Mode): در این حالت، مرورگر نقض‌های CSP را گزارش می‌دهد اما منابع را مسدود نمی‌کند. این برای آزمایش و ارزیابی یک CSP قبل از اجرای آن مفید است. CSP با استفاده از هدر `Content-Security-Policy-Report-Only` ارسال می‌شود.
پیاده‌سازی CSP: یک راهنمای گام به گام
پیاده‌سازی CSP ممکن است دلهره‌آور به نظر برسد، اما با دنبال کردن یک رویکرد ساختاریافته، می‌توانید به طور موثر اپلیکیشن وب خود را ایمن کنید.
۱. با یک خط‌مشی فقط-گزارش شروع کنید
با استقرار یک CSP در حالت فقط-گزارش شروع کنید. این به شما امکان می‌دهد تا تخلفات را بدون ایجاد اختلال در عملکرد وب‌سایت خود نظارت کنید. دستورالعمل report-uri یا report-to را برای ارسال گزارش‌های تخلف به یک نقطه پایانی مشخص، پیکربندی کنید.
هدر مثال (فقط-گزارش):
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report
۲. گزارش‌های تخلف را تحلیل کنید
گزارش‌های تخلف را به دقت تحلیل کنید تا مشخص شود کدام منابع مسدود شده‌اند و چرا. این به شما کمک می‌کند تا وابستگی‌های منابع وب‌سایت خود را درک کرده و آسیب‌پذیری‌های امنیتی بالقوه را شناسایی کنید.
گزارش‌های تخلف معمولاً به صورت محموله‌های JSON به نقطه پایانی report-uri یا report-to پیکربندی شده ارسال می‌شوند. این گزارش‌ها حاوی اطلاعاتی در مورد تخلف هستند، مانند URI مسدود شده، دستورالعمل نقض شده، و URI سند.
۳. خط‌مشی CSP را اصلاح کنید
بر اساس گزارش‌های تخلف، خط‌مشی CSP خود را اصلاح کنید تا به منابع قانونی اجازه دهید در حالی که همچنان یک وضعیت امنیتی قوی را حفظ می‌کنید. مقادیر منبع خاصی را برای منابعی که مسدود شده‌اند اضافه کنید. برای جلوگیری از استفاده از 'unsafe-inline'، استفاده از nonce یا هش برای اسکریپت‌ها و استایل‌های درون‌خطی را در نظر بگیرید.
۴. به حالت اجرایی بروید
هنگامی که مطمئن شدید خط‌مشی CSP شما منابع قانونی را مسدود نمی‌کند، به حالت اجرایی بروید. این کار هرگونه تخلف باقی‌مانده را مسدود کرده و یک لایه امنیتی قوی در برابر حملات XSS فراهم می‌کند.
هدر مثال (اجرایی):
Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report
۵. خط‌مشی CSP را نظارت و نگهداری کنید
CSP یک راه‌حل «تنظیم کن و فراموش کن» نیست. ضروری است که به طور مداوم خط‌مشی CSP خود را نظارت کرده و با تکامل وب‌سایت و ظهور تهدیدات امنیتی جدید، آن را به‌روزرسانی کنید. به طور منظم گزارش‌های تخلف را بررسی کرده و در صورت نیاز خط‌مشی را تنظیم کنید.
مثال‌های عملی CSP
بیایید به چند مثال عملی CSP برای سناریوهای مختلف نگاه کنیم:
مثال ۱: CSP پایه برای یک وب‌سایت ساده
این CSP به محتوا از همان مبدا اجازه می‌دهد و به تصاویر از هر منبعی اجازه می‌دهد.
Content-Security-Policy: default-src 'self'; img-src *
مثال ۲: CSP با منابع اسکریپت و استایل خاص
این CSP به اسکریپت‌ها از همان مبدا و از یک CDN خاص، و به استایل‌ها از همان مبدا و استایل‌های درون‌خطی اجازه می‌دهد.
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'
مثال ۳: CSP با Nonce برای اسکریپت‌های درون‌خطی
این CSP برای هر اسکریپت درون‌خطی به یک nonce منحصر به فرد نیاز دارد.
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'
HTML:
<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>
مهم: مقدار nonce باید به صورت پویا در سرور برای هر درخواست تولید شود. این کار از استفاده مجدد nonce توسط مهاجمان جلوگیری می‌کند.
مثال ۴: CSP محدود کننده frame-ancestors برای جلوگیری از کلیک‌جکینگ
این CSP از جاسازی صفحه در یک iframe در هر دامنه‌ای به جز `https://example.com` جلوگیری می‌کند.
Content-Security-Policy: frame-ancestors 'self' https://example.com
مثال ۵: یک CSP محدودکننده‌تر با استفاده از 'strict-dynamic' و یک جایگزین 'self'
این CSP از `strict-dynamic` برای مرورگرهای مدرن استفاده می‌کند در حالی که همچنان از مرورگرهای قدیمی‌تری که از آن پشتیبانی نمی‌کنند، پشتیبانی می‌کند. همچنین شامل یک `report-uri` برای نظارت بر تخلفات است.
Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report
به یاد داشته باشید که `{random-nonce}` را با یک مقدار nonce تولید شده پویا در سمت سرور جایگزین کنید.
CSP و اپلیکیشن‌های تک‌صفحه‌ای (SPAs)
پیاده‌سازی CSP در SPAها به دلیل ماهیت پویای این اپلیکیشن‌ها می‌تواند چالش‌برانگیز باشد. SPAها اغلب به شدت به جاوا اسکریپت برای تولید و دستکاری DOM متکی هستند، که در صورت عدم مدیریت دقیق می‌تواند منجر به نقض CSP شود.
در اینجا چند نکته برای پیاده‌سازی CSP در SPAها آورده شده است:
- از
'unsafe-inline'و'unsafe-eval'اجتناب کنید: تا حد امکان باید از این دستورالعمل‌ها در SPAها اجتناب شود. آنها به طور قابل توجهی امنیت اپلیکیشن شما را تضعیف می‌کنند. - از Nonce یا هش استفاده کنید: برای اسکریپت‌ها و استایل‌های درون‌خطی از nonce یا هش استفاده کنید. این رویکرد توصیه شده برای SPAها است.
- Trusted Types را در نظر بگیرید: Trusted Types یک API مرورگر است که به جلوگیری از آسیب‌پذیری‌های XSS مبتنی بر DOM کمک می‌کند. می‌توان آن را همراه با CSP برای افزایش بیشتر امنیت استفاده کرد.
- از یک فریمورک سازگار با CSP استفاده کنید: برخی از فریمورک‌های فرانت‌اند (مانند React با پیکربندی‌های خاص، Angular و Vue.js) ویژگی‌هایی را برای کمک به پیاده‌سازی آسان‌تر CSP ارائه می‌دهند.
سایر هدرهای امنیتی مهم فرانت‌اند
در حالی که CSP سنگ بنای امنیت فرانت‌اند است، هدرهای دیگر نقش حیاتی در ارائه یک استراتژی دفاعی جامع ایفا می‌کنند:
Strict-Transport-Security (HSTS)
هدر Strict-Transport-Security (HSTS) به مرورگر دستور می‌دهد که همیشه از HTTPS برای اتصال به وب‌سایت استفاده کند. این کار از حملات مرد میانی که سعی در تنزل اتصال به HTTP دارند، جلوگیری می‌کند.
هدر مثال:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age: مدت زمانی (به ثانیه) را مشخص می‌کند که مرورگر باید به یاد داشته باشد که فقط از طریق HTTPS به سایت دسترسی پیدا کند. مقدار 31536000 ثانیه (1 سال) برای محیط‌های production توصیه می‌شود.includeSubDomains: نشان می‌دهد که خط‌مشی HSTS برای همه زیردامنه‌های دامنه اعمال می‌شود.preload: اجازه می‌دهد تا دامنه در لیستی از دامنه‌های فعال شده با HSTS که در مرورگرها از قبل بارگذاری شده است، گنجانده شود. این امر مستلزم ارسال دامنه شما به لیست پیش‌بارگذاری HSTS است که توسط گوگل نگهداری می‌شود.
X-Frame-Options
هدر X-Frame-Options با کنترل اینکه آیا وب‌سایت می‌تواند در یک iframe جاسازی شود، از حملات کلیک‌جکینگ جلوگیری می‌کند.
هدر مثال:
X-Frame-Options: DENY
مقادیر ممکن:
DENY: از نمایش صفحه در یک iframe، صرف نظر از مبدا، جلوگیری می‌کند.SAMEORIGIN: اجازه می‌دهد صفحه در یک iframe نمایش داده شود فقط اگر مبدا iframe با مبدا صفحه مطابقت داشته باشد.ALLOW-FROM uri: اجازه می‌دهد صفحه در یک iframe نمایش داده شود فقط اگر مبدا iframe با URI مشخص شده مطابقت داشته باشد. توجه: این گزینه منسوخ شده است و ممکن است توسط همه مرورگرها پشتیبانی نشود.
توجه: دستورالعمل frame-ancestors در CSP راهی انعطاف‌پذیرتر و قدرتمندتر برای کنترل فریم‌بندی ارائه می‌دهد و به طور کلی بر X-Frame-Options ترجیح داده می‌شود.
X-XSS-Protection
هدر X-XSS-Protection فیلتر XSS داخلی مرورگر را فعال می‌کند. در حالی که CSP یک راه‌حل قوی‌تر برای جلوگیری از حملات XSS است، این هدر می‌تواند یک لایه دفاعی اضافی ایجاد کند، به ویژه برای مرورگرهای قدیمی‌تری که ممکن است به طور کامل از CSP پشتیبانی نکنند.
هدر مثال:
X-XSS-Protection: 1; mode=block
1: فیلتر XSS را فعال می‌کند.0: فیلتر XSS را غیرفعال می‌کند.mode=block: به مرورگر دستور می‌دهد تا در صورت شناسایی حمله XSS، صفحه را مسدود کند.report=uri: یک URL را مشخص می‌کند که مرورگر باید در صورت شناسایی حمله XSS، گزارشی به آن ارسال کند.
Referrer-Policy
هدر Referrer-Policy میزان اطلاعات ارجاع‌دهنده (referrer) که با درخواست‌ها ارسال می‌شود را کنترل می‌کند. اطلاعات ارجاع‌دهنده می‌تواند برای ردیابی کاربران در سراسر وب‌سایت‌ها استفاده شود، بنابراین کنترل آن می‌تواند حریم خصوصی کاربر را بهبود بخشد.
هدر مثال:
Referrer-Policy: strict-origin-when-cross-origin
برخی از مقادیر رایج:
no-referrer: هرگز هدر Referer را ارسال نمی‌کند.no-referrer-when-downgrade: هدر Referer را به مبداهای بدون TLS (HTTPS) ارسال نمی‌کند.origin: فقط مبدا (طرح، میزبان و پورت) را در هدر Referer ارسال می‌کند.origin-when-cross-origin: برای درخواست‌های بین-مبدا مبدا را و برای درخواست‌های همان-مبدا URL کامل را ارسال می‌کند.same-origin: هدر Referer را برای درخواست‌های همان-مبدا ارسال می‌کند، اما برای درخواست‌های بین-مبدا نه.strict-origin: فقط مبدا را زمانی ارسال می‌کند که سطح امنیتی پروتکل ثابت بماند (HTTPS به HTTPS)، اما هیچ هدر به مقصد با امنیت کمتر (HTTPS به HTTP) ارسال نمی‌کند.strict-origin-when-cross-origin: هنگام انجام یک درخواست همان-مبدا، مبدا را ارسال می‌کند. برای درخواست‌های بین-مبدا، مبدا را فقط زمانی ارسال می‌کند که سطح امنیتی پروتکل ثابت بماند (HTTPS به HTTPS)، اما هیچ هدر به مقصد با امنیت کمتر (HTTPS به HTTP) ارسال نمی‌کند.unsafe-url: URL کامل را در هدر Referer ارسال می‌کند، صرف نظر از مبدا. با احتیاط شدید استفاده کنید، زیرا این می‌تواند اطلاعات حساس را افشا کند.
Permissions-Policy (قبلاً Feature-Policy)
هدر Permissions-Policy (که قبلاً با نام Feature-Policy شناخته می‌شد) به توسعه‌دهندگان اجازه می‌دهد تا ویژگی‌ها و APIهای مرورگر را به صورت انتخابی فعال و غیرفعال کنند. این می‌تواند به کاهش سطح حمله اپلیکیشن شما و بهبود حریم خصوصی کاربر کمک کند.
هدر مثال:
Permissions-Policy: geolocation=()
این مثال API موقعیت جغرافیایی (geolocation) را برای وب‌سایت غیرفعال می‌کند.
ویژگی‌های دیگری که می‌توان با Permissions-Policy کنترل کرد عبارتند از:
cameramicrophonegeolocationaccelerometergyroscopemagnetometerusbmidipaymentfullscreen
تنظیم هدرهای امنیتی روی پلتفرم‌های مختلف
روش تنظیم هدرهای امنیتی بسته به وب سرور یا پلتفرمی که استفاده می‌کنید، متفاوت است. در اینجا چند مثال رایج آورده شده است:
Apache
می‌توانید هدرهای امنیتی را در آپاچی با افزودن آنها به فایل .htaccess یا فایل پیکربندی سرور (httpd.conf) تنظیم کنید.
پیکربندی مثال .htaccess:
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Frame-Options "DENY"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Nginx
می‌توانید هدرهای امنیتی را در Nginx با افزودن آنها به بلوک سرور در فایل پیکربندی Nginx (nginx.conf) تنظیم کنید.
پیکربندی مثال Nginx:
server {
listen 443 ssl;
server_name example.com;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Frame-Options "DENY";
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy "strict-origin-when-cross-origin";
...
}
Node.js (Express)
می‌توانید هدرهای امنیتی را در Node.js با استفاده از میان‌افزارهایی مانند Helmet تنظیم کنید.
مثال با استفاده از Helmet:
const express = require('express');
const helmet = require('helmet');
const app = express();
app.use(helmet());
// در صورت نیاز CSP را سفارشی کنید
app.use(helmet.contentSecurityPolicy({
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'", "https://cdn.example.com"],
styleSrc: ["'self'", "'unsafe-inline'"],
imgSrc: ["'self'", "data:"],
reportUri: '/csp-report'
},
}));
app.get('/', (req, res) => {
res.send('Hello World!');
});
app.listen(3000, () => {
console.log('Server listening on port 3000');
});
Cloudflare
Cloudflare به شما امکان می‌دهد تا هدرهای امنیتی را با استفاده از Page Rules یا Transform Rules خود تنظیم کنید.
تست کردن هدرهای امنیتی شما
پس از پیاده‌سازی هدرهای امنیتی، تست کردن آنها برای اطمینان از عملکرد صحیحشان بسیار مهم است. چندین ابزار آنلاین می‌توانند به شما در تحلیل هدرهای امنیتی وب‌سایتتان کمک کنند:
- SecurityHeaders.com: یک ابزار ساده و موثر برای تحلیل هدرهای امنیتی.
- Mozilla Observatory: یک ابزار جامع برای تست امنیت وب‌سایت، از جمله هدرهای امنیتی.
- WebPageTest.org: به شما امکان می‌دهد هدرهای HTTP را در نمودار آبشاری (waterfall chart) مشاهده کنید.
نتیجه‌گیری
هدرهای امنیتی فرانت‌اند، به ویژه خط‌مشی امنیت محتوا (CSP)، برای محافظت از اپلیکیشن‌های وب در برابر حملات مختلف و افزایش امنیت کاربران ضروری هستند. با پیاده‌سازی و نگهداری دقیق این هدرها، می‌توانید به طور قابل توجهی خطر XSS، کلیک‌جکینگ و سایر آسیب‌پذیری‌های امنیتی را کاهش دهید. به یاد داشته باشید که با یک خط‌مشی فقط-گزارش شروع کنید، گزارش‌های تخلف را تحلیل کنید، خط‌مشی را اصلاح کنید و سپس به حالت اجرایی بروید. به طور منظم هدرهای امنیتی خود را نظارت و به‌روزرسانی کنید تا با تکامل وب‌سایت و ظهور تهدیدات جدید، آن را امن نگه دارید.
با اتخاذ یک رویکرد پیشگیرانه به امنیت فرانت‌اند، می‌توانید اپلیکیشن‌های وب امن‌تر و قابل اعتمادتری بسازید که از کاربران و کسب و کار شما محافظت می‌کنند.